[Google Cloud] あの機能/サービスは今！？ #cm_google_cloud_adcal_2024

[Google Cloud] あの機能/サービスは今！？ #cm_google_cloud_adcal_2024

クラスメソッドのGoogle Cloud Advent Calendar 2024

クラスメソッドのGoogle Cloud Advent Calendar 2024

#Google Cloud (GCP)
#Google BigQuery
みかみ

みかみ

facebook logohatena logotwitter logo
Clock Icon2024.12.07

こんにちは、みかみです。

本記事は、クラスメソッドのGoogle Cloud Advent Calendar 2024 の 7 日目のエントリです。

Google Cloud 好きなクラスメソッド社員が紡ぐ今年のクラスメソッド Google Cloud Advent Calendar 2024、最終日の25日までお楽しみいただけたら幸いです！

https://qiita.com/advent-calendar/2024/cm-google-cloud

はじめに

早いもので 2024 年も残りわずかとなりました。

個人的には、Google Cloud をさわり始めてから気づけば早5年。年の経つのは早いものです。そしてクラウドサービスの進化の速さには、いつも驚かされています。
今回は、自分が過去にどんな検証をしたか振り返りをかねて、過去ブログで投稿した当時の機能やサービスが今どうなっているか、関連情報含めて確認してみました。
「そういえばそんな時代もあったなー」と、軽くお付き合いいただけたら嬉しいです。

なお、本エントリ内の動作確認に必要な環境（API の有効化や CLI 実行環境、操作に必要な権限付与など）は準備済みであるものとします。
また、文中、AWS のアカウント ID や Google Cloud プロジェクト ID など一部の文字は伏字に変更しています。

BigQuery INFORMATION_SCHEMA

BigQuery のシステムメタデータを確認できる INFORMATION_SCHEMA ビューですが、BigQuery の機能追加/変更に伴いずいぶん新しいビューが増え、ビューのスキーマもだいぶ変わっています。

特に JOBS_TIMELINE_BY_* で BigQuery ジョブのより詳細な情報を確認できたり、以前はデータセットごとにしか確認できなかったストレージデータ量を TABLE_STORAGE_* ビューから一括で確認することができるようになり、より便利になりました。

例えば以下のクエリで、東京リージョンの BigQuery の各データセット＆テーブルのデータ量を確認することができます。

SELECT
  table_schema,
  table_name,
  total_rows,
  table_type,
  total_logical_bytes,
  total_physical_bytes,
  storage_last_modified_time
FROM
  `region-asia-northeast1`.INFORMATION_SCHEMA.TABLE_STORAGE_BY_PROJECT
order by 1, 2

bq_select_table_storage

BigQuery ストレージ料金プランの見直しにも大活躍です！

なお、TABLE_STORAGE_* ビューを参照するために必要な以下の2つの権限は、プロジェクトオーナーロールには含まれておりません。

  • bigquery.tables.get
  • bigquery.tables.list

TABLE_STORAGE_* ビューを参照しようとした時に Access Denied なエラーが発生する場合は、上記権限があるかどうかご確認ください。

サービスアカウントキー認証

以前は、AWS 等の他のパブリッククラウドやサードパーティツールなどから Google Cloud にアクセスする際、サービスアカウントキーを使ってアクセスしていましたが、現在サービスアカウントキーによる認証は推奨されていません。
キーを発行すると、そのキーが漏洩した場合のリスクがつきまといますし、誰がキーを利用したか確認できないためです。

代わりに Workload Identity 連携で、サービスアカウントキーなしで認証することができます。
AWS からのアクセスの場合、STS（Security Token Service）で取得した一時的な認証情報を使って Workload Identity プールで認証を行い、Workload Identity プールに関連づけられたサービスアカウントの権限を借用して Google Cloud のリソースにアクセスする仕組みです。

Workload Identity 連携を使用するために必要な設定は以下です。

  1. IAM ロールを作成して EC2 にアタッチ（AWS）
  2. サービスアカウントを作成して必要なロールを付与（Google Cloud）
  3. Workload Identity プールとプロバイダを作成（Google Cloud）
  4. Workload Identity プールとサービスアカウントを連携して、認証構成ファイルを作成（Google Cloud）
  5. EC2 に認証情報構成ファイルを配置（AWS）

Workload Identity プールとプロバイダの作成、プールとサービスアカウントの連携を設定する必要がありますが、はじめに一度設定してしまえばよいので、サービスアカウントキー利用時のキーローテーションの考慮など不要になり、よりシンプルでセキュアな運用ができるのではないかと思います。

実際にやってみます。

1. IAM ロールを作成して EC2 にアタッチ（AWS）

まずは、AWS で Workload Identity を利用するためのポリシーとロールを作成して、EC2 インスタンスにアタッチしておきます。

aws_role_test_mikami_WI

EC2 のマシンイメージは Amazon Linux 2023 を使用しています。

2. サービスアカウントを作成して必要なロールを付与（Google Cloud）

続いて Google Cloud で、AWS からのアクセス時に利用する Google Cloud サービスアカウントを作成して、「BigQuery 管理者」ロールを付与しました。

g_sa_test_wi

動作確認目的のため強めの「「BigQuery 管理者」をつけましたが、付与するロールはご利用環境に合わせて適切な権限になるようご検討ください。

3. Workload Identity プールとプロバイダを作成（Google Cloud）

引き続き Google Cloud で、Cloud Shell から以下のコマンドを実行して、Workload Identity のプールとプロバイダを作成しました。

gcloud iam workload-identity-pools create pl-test-wi \
    --location="global" \
    --description="Workload Identity確認用" \
    --display-name="pool for Workload Identity"

gcloud iam workload-identity-pools providers create-aws aws-provider \
  --location="global" \
  --workload-identity-pool="pl-test-wi" \
  --account-id="[AWS_ACCOUNT_ID]" \
  --attribute-mapping="google.subject=assertion.arn,attribute.aws_role=assertion.arn.contains('assumed-role') ? assertion.arn.extract('{account_arn}assumed-role/') + 'assumed-role/' + assertion.arn.extract('assumed-role/{role_name}/') : assertion.arn"

4. Workload Identity プールとサービスアカウントを連携して、認証構成ファイルを作成（Google Cloud）

続いて、3.で作成した Workload Identity プールと、2.で作成したサービスアカウントを関連付けて、1.の AWS IAM ロールが Google Cloud のサービスアカウントの権限借用を実行するための権限を付与します。

gcloud iam service-accounts add-iam-policy-binding "sa-test-wi@[PROJECT_ID].iam.gserviceaccount.com" \
    --project="[PROJECT_ID]" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/[PROJECT_NUMBER]/locations/global/workloadIdentityPools/pl-test-wi/attribute.aws_role/arn:aws:sts::[AWS_ACCOUNT_ID]:assumed-role/test_mikami_WI"

その後、Workload Identity プールの認証情報ファイルを作成しました。

gcloud iam workload-identity-pools create-cred-config \
    projects/[PROJECT_NUMBER]/locations/global/workloadIdentityPools/pl-test-wi/providers/aws-provider \
    --service-account=sa-test-wi@[PROJECT_ID].iam.gserviceaccount.com \
    --aws \
    --enable-imdsv2 \
    --output-file=wi_cred_config.json

5. EC2 に認証情報構成ファイルを配置（AWS）

4.で作成した認証情報ファイルを EC2 インスタンスにアップロードし、EC2 インスタンスで以下のコマンドを実行して環境変数に設定しておきます。

export GOOGLE_APPLICATION_CREDENTIALS=`pwd`/wi_cred_config.json

実行

今回、Python コードから google-cloud-bigquery ライブラリで BigQuery にアクセスするので、Python 実行環境を準備します。

EC2 インスタンスで以下のコマンドを実行し、pip をインストール後に、google-cloud-bigquery クライアントライブラリをインストールしました。

$ sudo yum -y install python-pip
$ pip install google-cloud-bigquery

以下の、dataset_1.dogs テーブルデータを参照する Python コードを、ac2bq.py というファイル名で保存しました。

from google.cloud import bigquery

client = bigquery.Client(project='[PROJECT_ID]')

QUERY = (
    'SELECT name FROM dataset_1.dogs'
)
query_job = client.query(QUERY)
rows = query_job.result()

for row in rows:
    print(row.name)

実行してみます。

[ec2-user@ip-10-0-1-158 ~]$ python3 ac2bq.py 
シベリアンハスキー
秋田犬
シェパード
ラブラドールレトリバー
ボルゾイ
柴犬
コーギー

無事、サービスアカウントキーなしで BigQuery にアクセスすることができました。

BigQuery マルチステートメントトランザクション

以前は BigQuery では複数 SQL に対するトランザクション処理がサポートされていなかったため、一連の処理の途中で SQL エラーが発生した場合のロールバック処理は明示的に自分で記述しておく必要がありました。
ずいぶん前からですが BigQuery でもマルチステートメントトランザクションがサポートされるようになっています。

クエリエディタから SQL を実行すると、画面上でも ROLLBACK が実行されたことが確認できます。

bq_transaction_rollback

永続テーブルの作成など、DDL ステートメントはトランザクションではサポートされておらず、エラーになってしまうのでご注意ください。

Billing データ（BigQuery へのデータエクスポート）

Billing データを BigQuery にエクスポートしておくとコスト管理に便利です。
以前は1種類の利用料金データがエクスポートできるだけでしたが、現在は利用料金の詳細データと、価格マスタデータも出力できるようになっています。

billing_export_data

詳細データには resource.name 項目もあるので、例えば VM インスタンスごとの料金や Cloud Storage バケットごとの料金など、個々のリソース単位の利用料金も確認することができます。
また、Google Cloud の価格は改定されたり、為替レートが利用費に影響することがありますが、料金データ（価格マスタデータ）で SKU（各サービスの最小管理単位）ごとの価格情報や米ドルから現地通貨への為替レートが確認できるので、リソース使用量のモニタリングや傾向分析など、より精度の高いコスト管理を行うことが可能になります。

標準データの項目はすべて詳細データにも含まれるので、標準データと詳細データの両方をエクスポートする必要はありません。より詳細なコスト管理が必要な場合は、標準データではなく詳細データのエクスポートをご検討ください。

BigQuery データファイル出力

以前は SQL で BigQuery データをファイル出力することはできませんでしたが、現在は（かなり前からですが）EXPORT DATA 構文で SELECT 結果を直接ファイル出力できるようになっています。

AWS Redshift から BigQuery に移行する際、Redshift の UNLOAD 文を BigQuery でどう実現するか検討したのも良い思い出です。

CSV 以外にも JSON や PARQUET などのファイルフォーマットが指定できたり、圧縮タイプの指定も可能です。

以下の SQL で、dataset_1.temp_json テーブルの col_1, col_2 カラムデータを、gs://test-mikami バケットに GZIP 圧縮の JSON ファイルとして出力してみました。

EXPORT DATA
  OPTIONS (
    uri = 'gs://test-mikami/20241207/temp_*.json.gz',
    format = 'JSON',
    compression='GZIP',
    overwrite = true
  )
AS (
  select col_1, col_2 FROM dataset_1.temp_json
)

export_data_json

解凍して中身も確認してみます。

{"col_1":{"key":"val"},"col_2":{"key":"val"}}

SQL で指定した通り、テーブルの JSON 型カラムのデータがファイル出力できました。

なお、個人的に少し残念に思っているのが、データ量が多い場合などに、出力するファイルサイズやファイル数をコントロールできないことです。
1ファイルの最大サイズや最大出力行数などが指定できるようになると、もっと嬉しいです！

BigQuery クエリプラン（実行計画）確認

以前から BigQuery クエリエディタで SQL のクエリプランが確認できましたが、現在はよりわかりやすく表示されるようになりました。

bq_query_plan_detail

新しく追加された実行グラフ表示では、SQL のステップごとの処理の流れが視覚的にわかりやすく、どのステップで時間がかかっているかもすぐにわかるようになっています。

bq_query_plan_graph

過去に実行したクエリでも、ジョブ履歴からエディタ表示することができるので、クエリプランの確認が可能です。

SQL 実行時間の詳細確認や最適化に活躍する、便利なアップデートで嬉しいです。

Dataprep（ローコードなデータパイプラインサービス）

以前、ノンコーディング（ローコーディング）でデータパイプラインを構築できる便利な Dataprep を試してみましたが、現在 Dataprep の他にも、ローコードな GUI 操作でデータパイプラインを構築できるサービス、Application Integration がラインナップに加わっています。

Dataprep がその名前「データプレパレーション」の表す通り、データのクレンジングや変換を得意としていることに対して、Application Integration では Google Cloud 以外のクラウドやサードパーティツールを含む豊富なコネクタを利用することができ、こちらもその名の通り他のサービスやアプリとの統合を得意とするサービスだと思います。

以下のクイックスタートを試してみました。

GUI 操作でトリガーとタスクを配置して、インテグレーションを作成していきます。何の処理でどのタスクを使うのか、Input と Output に何を指定するのか、Data Mapping タスクの設定方法など、初めは戸惑うところもありそうですが、プルダウンから必要なタスクを選択して配置し、タスク同士を繋げて必要な項目を入力/選択してゆくと、wikipedia API から取得したデータをメール送信するワークフローが簡単に作成できました。

apl_int_flow

動作確認も画面から簡単に実行できます。

apl_int_test

本当にメールが送信されたか確認してみます。

apl_int_mail

期待通り、API から取得したデータをメール送信することができました。

なお、Application Integration にも他のサービス同様無料枠がありますが、プロジェクト単位ではなく請求先アカウント単位で消費されるので、ご注意ください。

まとめ（所感）

継続的で迅速なアップデートのおかげで、クラウドサービスはますます便利でセキュアに利用できるようになり、本当に感謝です！
構築済みのシステムにも定期的な見直しを行うことで、より効率的な運用保守が実現できると思います。また、趣味で試した機能やサービスも、「今」を確認してみると、新しい発見があって面白いかもしれません。
これからも、Google Cloud の進化を一緒に楽しんでいきましょう！

明日、8 日目の クラスメソッドのGoogle Cloud Advent Calendar 2024 の投稿は エノカワ さんの予定です。
引き続きお楽しみいただけますと幸いです！

参考

Share this article

facebook logohatena logotwitter logo

関連記事

Cloud Workstationsを構築する際の考慮事項を整理してみた #cm_google_cloud_adcal_2024

Cloud Workstationsを構築する際の考慮事項を整理してみた #cm_google_cloud_adcal_2024

User avatar
suto
2024.12.12
BigQuery のリソースへのアクセスを IAM Conditions とタグで制御する方法をまとめてみた #cm_google_cloud_adcal_2024

BigQuery のリソースへのアクセスを IAM Conditions とタグで制御する方法をまとめてみた #cm_google_cloud_adcal_2024

User avatar
hanzawa.yuya
2024.12.11
Workflows で並列実行ステップのエラーをキャッチした際の挙動を確認してみた #cm_google_cloud_adcal_2024

Workflows で並列実行ステップのエラーをキャッチした際の挙動を確認してみた #cm_google_cloud_adcal_2024

User avatar
エノカワ
2024.12.10
Google CloudのGCEインスタンスにSplunk Enterpriseをインストールしてみた #cm_google_cloud_adcal_2024

Google CloudのGCEインスタンスにSplunk Enterpriseをインストールしてみた #cm_google_cloud_adcal_2024

User avatar
根本夏瑠
2024.12.09
Classmethod's white logo
Facebook's logo
X's logo
YouTube's logo

© Classmethod, Inc. All rights reserved.